COMMENT ⊗   VALID 00022 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	@Device[Dover]
C00004 00003	@F3[Paper submitted to the Seventh International Joint Conference on
C00005 00004	@Section[OUTLINE]
C00011 00005	@Begin[Quotation, Indent 0]
C00016 00006	@Section[Introduction]
C00024 00007	@Section[EURISKO Itself - What it does, and how]
C00039 00008	@Section[Scenario]
C00042 00009	@SubSection[Part 1: Designing and constructing a new knowledge base.]
C00054 00010	@SubSection[After input, EURISKO thinks]
C00068 00011	@SubSection[Exploration stage]
C00074 00012	@SubSection[Reconfiguration stage]
C00083 00013	@SubSection[Closing remarks]
C00086 00014		<Transition>
C00087 00015	@Section[Underpinnings]
C00099 00016	Below we discuss the perhaps-less-obvious reasons why automating the
C00107 00017		<What are heuristics?>
C00116 00018		<Known methods of generating heuristics>
C00124 00019	Conclusion
C00127 00020	Acknowledge
C00141 00021		References
C00149 00022	Meta Comments
C00154 ENDMK
C⊗;
@Device[Dover]
@Modify[Verbatim, Break Before]
@Modify[Display, Break Before]
@Modify[ProgramExample, Break Off]
@Modify[Example, Break Before]
@Style[Indent 0]
@Make[Article]
@SpecialFont[F1=TimesRoman14]
@SpecialFont[F2=GACHA10]
@SpecialFont[F3=Cream10]
@Font[TimesRoman10]
@F3[Paper submitted to the Seventh International Joint Conference on
Artificial Intelligence, Vancouver, B.C., August 24-28, 1981]
 
@Begin[Center]
@b[@F1[


Overview of EURISKO
]]


Russell Greiner
Heuristic Programming Project
Computer Science Department
Stanford University
Stanford, California 94305


@b[Abstract]
@End[Center]

@Section[OUTLINE]
@BEGIN[Verbatim]

=== ABSTRACT ===

	- What is EURISKO? [What is its task, & how will EURISKO achieve it?]
	- What is this paper about?

=== INTRODUCTION  ===

i-I. Defn of EURISKO
  - Search for interesting facts
  - (Side task) facilitating input of new KBs

i-II. Description of this paper
  - Scenario
  - Justify how tasks interrelate (KB input and Exploration)

i-III. Purpose of paper, and Audience

=== CONTENT ===

c-I. EURISKO itself
  - How does EURISKO work?
	Based on AM program (given its execution loop)
  - Difference from AM - able to expand -- as able to explore into 
	Heuristics
	Control Structure
	Representation

c-II. Scenario - dialog between user and EURISKO to build KB
  - Intro and Disclaimer
  - Input
	Actual dialog
	Eurisko's thoughts and initial design
  - Exploration
	At user request
	As general improvement process
  - Reconfiguration
  - Closing comments


c-III. Underpinnings
  - Why need to worry about KB input?  
[Semantics]
  - Very important, as above capabilities are complex
  - Must be modifiable, and self-descriptive
	[ie described in its own terms/formalism]
  - Hence RLL (pre-MRS days) needed
	Explain why (i) needed Rep'n Language
		    (ii) others lackings
  - EURISKO uses same philosophy - (leave everything explicit)

c-V. Structure of Components [plug for RLL]
  - "To everything, a unit" philosophy
	So agenda, process, various LISP fns, ... are units
	[See RLL papers to see that things like Slots, Variables, ... 
	 are as well]
  - Organized into `hierarchies' - so (inter)relations are explicit
  - Many things have multiple rep'ns (eg source/compiled code)
	Different perspectives for reasoning/running/meta-...
	[Cognitive Economy]
  - Ease of user (eventually EURISKO) interaction

c-VI. Why it pays to automate discovery of Heuristics
  - What are heuristics?
	Plug ToH paper
	They form a field of study, like Mathematics
	But heuristics are slightly different
	Meta (ie can view itself)

c-VII. Rules in particular
  - Big win to define them as more that simple If/Then
	Can split up these action parts
	Can describe these (factoring out commonalities to form HighLevel Language)
	  [eg domain of applicability]
	Declaritive information:
	  Who used it, average run time, ...
  - To generate new/modify existing ones
	Relation to other rules
	[Eg specialization, analogous]
  - View of many things as functions - so derive vocabulary of domain/range,
	specification [semantics?]
	(like wise for Slots, agenda processing mechanisms)
	So like automatic programming - sticking together (declarative) components
	into running procedures
	[Also store facts about regular LISP functions]

c-IX. Self Improvement

=== CONCLUSION  ===

n-I. Research Plan
  - To get Heuristics, need to first get domains, for these facts to be
	heuristics about
  - Wide (hence unbiased) set of KBs - natural & artificial
  - Early on, have heuristic for developing new heuristics, and proposing new
	representations (like AP)

n-II. Current state
  - Smattering of many KBs - ranging from BIOLOGY to SLOT vocabulary
  - Interest of Mostow, 
	thru MRS, Dart [Genesereth], Intelligent Agenda [Genesereth]
	? Rand [Rick], Resolution [Hines], ..
	   From both perspectives.

=== ACKNOWLEDGEMENTS ===

-----
Where to put things like the details of EURISKO control loop - esp why
the PostMortem step provides a handy niche for introspecting.
@END[Verbatim]
@Begin[Quotation, Indent 0]
@F2[ABSTRACT]

The EURISKO system uses AM's [Lenat76] technique
of investigating "interesting" phenomena
to "discover" new facts.
Unlike AM,
(which probed only a subset of mathematics,)
EURISKO is designed to perform this exploration
on a wide variety of domains,
ranging from VLSI design to mathematics.
To avoid placing any restrictions on the nature of either the domain, or the task,
it is essential that EURISKO be able to adapt
itself to each of these fields as automatically as possible.
EURISKO's ability to generate and subsequently incorporate
the new heuristics, representations and control and inference procedures
appropriate to a given field facilitates the
input, and subsequent processing,
of each domain.
This versatility is achieved by
leaving all of EURISKO's processes and components
in a visible, and easy to modify form.
This paper outlines how the EURISKO system works,
describing in particular the processes it uses to produce new,
domain-dependent heuristics.
A major part of this discussion is spent defining what a
representation language language is, and why EURISKO
had to be build on one such system, RLL.
@End[Quotation]
@NewPage
@Section[Introduction]

@SubSection[Defn of EURISKO]
The EURISKO (Greek for "I discover") project is a rather ambitious attempt to
search for interesting facts about the world in general.
Its basic approach is an AM-like [Lenat76] guided exploration:
The goal is to extend and enhance a small starting
nucleus of facts about some domain,
(e.g. mathematics,)
by conjecture new assertions.
This is achieved by meandering through that domain,
generating new and potentially interesting concepts in the process.
As a computer program, EURISKO is of course dependent on 
Knowledge Bases (KBs)
@Foot[1. Throughout this paper we use the term "Knowledge Base" 
to refer to the inference procedures as well
as the domain facts.  This is slightly non-standard.]
input by the user to supply its domain information.
For this reason it is critical that EURISKO facilitate the incorporation
of new KBs.
This is achieved by storing, within the core EURISKO system, a body
of KBs which each house information relevant to some aspect of this KB-building task.

So, for example, there is a KB devoted to describing
various representational issues,
(which includes, for example, relevant features of 
various currently used representation languages,)
another which discusses inference and control mechanisms,
(e.g. knowledge about constructing and using blackboard models, or backward chaining
production rule systems, or agenda processing,)
and a third which attempts to generate new heuristics
relevant to a new domain (Section ? discusses this in detail).
EURISKO also maintains a seperate KB
in which it stores information about its own internal processing.
We will later discuss why this is useful, and how it will
enable EURISKO to improve its own performance:
that is, how such information will help
EURISKO to accomplish its chores (of KB input and 
domain exploration) more efficiently, and with a higher rate of success.

@Foot[2.It is worth noting that the EURISKO system will be continuously
growing and evolving.  
Each time a user creates a new domain, that KB is added
to the corpus of information available to all EURISKO users.
In addition, many of the KBs,
such as those which are dedicated to the task of KB construction,
will expand as new data 
(in the form of new categories of user-input KBs) is enterred.]

@SubSection[Overview of Paper]
The next section presents a quick outline of EURISKO's mission,
and how this is achieved.
This is followed by a sample EURISKO-User dialog,
which will further illustrate how the EURISKO system will function,
and in particular, how it exploits its KB-building KBs.
This scenario will illustrate the basic mechanisms
EURISKO uses to aide the user in
designing, constructing and using a knowledge base.
The rest of the paper provides many of details of how EURISKO works.
First is a sketch of the control mechanism EURISKO employs.
Several of EURISKO's constituent parts are then discussed:
Section ? explains why EURISKO coud not perform its tasks,
were it built on a standard representations language. 
Based on the stingent requirements EURISKO places on its underlying language,
(i.e. the rl on which it is built,)
we will show why a rlL is needed,
and then overview the RLL system we developed to fill this need.
Next, Section ?+1 explains why automating the discovery and incorporation of 
heuristics is worthwhile, and then provides a glimpse into the mechanisms
EURISKO will employ for this task.
This is followed by a brief description of how we are actually implementing
EURISKO in general,
and its approach to heuristics in particular.

@Subsection[Purpose of Paper, and Audience]
This paper is written to serve several functions and its intended audience
includes several, not necessarily distinct, groups.
A quick overview of the whys and hows of the full EURISKO system
is provided for those curious about the nature of this proposed program.
The brief excursions to describe relevant representational and implementational
issues are intended for those wishing to eventually use either EURISKO, or
some similar system.
This paper should also demonstrate the utility of rlls,
as it provides an example of a system which would not be possible without
so versatile and flexible a language.
The final audience are potential members of the eventual EURISKO community.
As we will reiterate in the conclusion,
we hope to establish a network of EURISKO users,
each implementing a KB to be incorporated within this evolving EURISKO system.
This paper should provide provide some encouragement in that direction,
at least to researchers now searching 
for the appropriate expert-system-building-system for constructing their
application KB.
@Section[EURISKO Itself - What it does, and how]

@SubSection[Motivate how EURISKO was an extension of AM]
To provide more detail into EURISKO's exploration process, and to discuss why
this approach was taken, it is necessary to understand a bit about
how EURISKO's parent program, the AM system [Lenat76], worked.
We will therefore digress to present a very short description of this program;
indicating which of its features lead to its "wins", and, importantly,
what aspects proved to be shortcomings in the long run.

The AM program started with a small set of 
set-theoritic primitives, and proceeded to generate other new and,
interesting mathematical concepts.
AM's underlying loop was fairly straightforward --
it would select the top task from its agenda of things-to-do,
(which was, by its definition, the most interesting)
and execute it.
Each task performed one of two basic functions:
it either created a new unit, (defined as a specialization of some existing unit,)
or filled in the value of some particular slot of some particular unit.
(AM began with a non-extendable collection of some <?50?> types of slots,
including Definition, IsA and Specializations.)
{Footnote: use of Frame notation: Unit Slot ?Facet?. See [Minsky],
[Bobrow & Winograd].}
A task might also have some side effects.  
For example, it might cause another task to be placed on the agenda.
Or it might twiddle some parameter which contributed to AM's "interest" function.
(E.g. the focus of attention would be shifted to reflect the unit which
AM was currently processing.)

To run, each task first selects the appropriate rule(s) from its
fixed battery of built-in rules, and then "fires" these.
AM's collection of 350 rules proved sufficient to propel AM from
the rudiments of set theory up through some non-trivial number theory conjectures
(e.g. the fundamental theory of arithmetic, and Goldbach's conjecture).

Many factors contributed to the impressive success of this enterprise:
One was AM's ability to generate new concepts, which it could then
reason about, and fill in.
Another was its agenda mechanism which, together with its "interest criteria",
permitted AM to investigate what appeared to be interesting at any given time.  
Its processing was fairly modular, thanks to
the bite-size declarative rules
it used to generate new concepts and to fill in values of its sparse units.
(this is as opposed to hardwired procedures).
Finally, AM kept a symbolic list of reasons for all of its actions,
which were stored on the products resulting from their execution.
AM could then use this information to reason about the utility of these various
processes, based on the success rates of their results.

@i[But we come here to bury AM, not to praise it.]

AM's limitations are, in retrospect, also quite prominent.
For example, it was never
able to reason about the concepts it developed {\sl in terms natural
to that concept}.  
It was therefore bogged down by its need to reason 
using set-theory terms, even when dealing with number theory concepts.
Another problem was that all of AM's structures and facets, as well as rules,
were honed towards this particular, set related domain.
The fact that these were all implicitly coded into AM meant that neither
AM nor anyone else could adjust or modify these rules, or readily add new ones.
Similarly AM could not ever reason about any of its internal functions,
(such as the ones used to compute a concept's interest,
to process the agenda, or to execute a task,) much less change them.
AM further lacked all of the provisions necessary to
"learn by being taught" (such as a linguistic front end).
This facility is absolutely essential for any 
system which hopes to incorporate any arbitrary new domains of knowledge.

Of course, it should not be surprising to see
so many objections listed above;
AM was not designed to accomplish the demanding task assigned to EURISKO.
That list merely indicates the things which will be done differently
in EURISKO.
In addition to many minor alterations,
(for example, EURISKO can accomondate multiple agendae (where more than
one can be "swapped in" at any given time; and EURISKO can accept 
arbitrary types of tasks,)
the major change from AM to EURISKO is in how explicit and adaptable
the system itself is.
Essentially everything in EURISKO is explicit, and easy to modify.
(We will see later that these EURISKO components are represented no differently
than standard domain facts.  They can therefore be edited in 
exactly the same manner, in fact, even using the same editing functions.)
Currently the user is responsible for performing almost all of the
significant changes; in the near term we expect EURISKO itself to 
improve its own performance through such `internal' alterations.

@Section[Scenario]

@SubSection[An imaginery dialog between user and EURISKO to build KB]

To provide some foundation for the rest of the paper,
we present the following imaginary scenario, 
to outline the basic ontogeny of a KB built and used by the EURISKO system.
The Anglicized dialog is NOT designed to convey
the precise details of EURISKO's activities,
only the flavor.
For example,
the actual interactions will not be in English,
but rather in a language built from RLL (see section ?).
This dialog should indicate
the sort of facilities the full eventual EURISKO system will have,
and in particular, how it is able to use its wealth of KBs in the
design, construction and use of the user's KB.

This section has four parts.  The first three are devoted to sketching
the EURISKO-user interactions with respect to this VLSI-Design KB:
part 1 deals with the design and creation of this KB, part 2 discusses how
this KB will be used, by both EURISKO and by the user, and part 3 shows
how readily this KB may be improved (or, in general, modified).
The final part summarizes this whole interplay, and comments on
salient features of each activity.

To the skeptics reading this paper, please bear with the outlandish seeming
claims in this section.
The rest of this paper will propose tangible processes 
(as well as point to existent code)
which achieves many of these results.
@SubSection[Part 1: Designing and constructing a new knowledge base.]

Sentences surrounded in braces ("{" and "}") are my comments.
They are often used to indicate that, for brevity,
we are skipping over some text.

-----
@BEGIN[Verbatim]

User:	I want to input a KB.
EURISKO: What type of system is it? 
	(I now know about Design/Planning, Learning, CAI, Diagnosing, NL, ...)
U:	It will be a design task.
E:	Good. You probably want to enter a list of specifications,
	and expect, as output, a low level description of the designed component.
	Correct?
U:	Yes. How did you know?
E:	I have a pre-stored model for Design type of tasks. 
	(Earlier instances, from which I generalized, included
	designing molecular genetic experiments, designing new houses,
	and Automatic programming.)

	What will you be designing?
U:	VLSI {Very Large Scale Intergrated} circuits.
E:	I know nothing about that domain.
{Note EURSKO did know about designing, though.}
	What sorts of data should be stored in "static memory" --
	i.e. what are the background facts, which will remain the same from 
	design task to design task.
U:	Facts about Electronics,
	(e.g. various laws of electronics, and types of electrical components,)
	Rules of Planar Geometry and a descriptionof the Photo-Fabrication Process.
E:	I already know about Planar geometry, and will now load it in.
	But I know nothing about Electronics.
	Should there be a KB devoted to this field 
	(-- ie is this information very general)?
U:	Yes.	
E:	Describe this domain, Electronics.
U:	It is a subdomain of both Physics and Computer Science.
E:	I already KBs about both of these fields. Shall I pull them in?
U:	Sure.

{Here EURISKO finds a number of heuristics which the Electronic field should inherit:
For example, in domains of Physics, it is often true that
	Many "laws" are really slightly wrong,
	(as they are based on useful, but imprecise, approximations).
(This is true, for example, about Newtonian Mechanics, as compared to Einsteinian.)
So we may assume this is true for Electronic as well
-- i.e. it may be worth looking for a deeper model,
to "really" explains some observation, at least when the data 
seems contrary to the (superficial) model in use.

[Two comments:
First, this rule is, in fact, the result of another heuristic:
	Facts about the structure and pedagogy of domain X are often true for
	all subdomains of X.
Second, this search for deep models in NOT universally applicable;
it is NOT true about, say, Logic.
Here there is no dichotomy, as this is a well-defined artificial system.]

In the other parent domain, Computer Science,
	It is a common technique to describe an object from many different perspectives.
(consider a piece of code from first the declarative, 
and then the procedural point of view.)
This approach may prove valuable in the Electronics domain as well.}

{The user now aides EURISKO in creating this Electronics KB.
Upon completion of this task, he helps to construct the Photo-Fabrication KB, 
which is described as a subtype of the Designing KB.
We return after both of these conclude, as the VLSI dialog continues:}

E:	What categories of things changes from task to task?
U:	Diffusion masks, Timing Conditions, ALUs, Stipple Patterns, CIF Codes,
	PullUp and PullDown Transistors, Logical Gates, Electronic Components, ...
E:	I assume the PU and PD Transistors are like Electronic Transistors, and that
	Logical Gates and Electronic Components correspond to their namesakes in
	the Electronic KB.  
	And similarly the abstract function: Timing Conditions, is the same as its
	Electronic counterpart.
	But what are those other things?
U:	Each diffusion mask is an array of bits.
E:	(I know about arrays and bits from my general, 
	"CS data structures/types" KB.)
	How is it used?
U:	It serves as a stencil, when imprinting the chip.
E:	I recognize Imprinting from the just enterred Photo-Fabrication KB,
	and know of stencil from my Art KB.

{As the dialog continues, the user defines the other new terms.
Whenever possible EURISKO attempts to "ground" these new concepts in
terms of more familiar, previously defined ones. So, for example,
new concepts which
closely correspond to things in the Electronic KB,
(e.g. VLSI's ACL is matched to Electronic's ROM,) are so linked. 
(This employs a sophisticated analogy-finding process.
As usual, there is a whole KB devoted to storing such facts about such
analogizing-processes.)}

E:	How will these things be used? How should they be orgranized?
	How do they interrelate?
U:	The following things are components:
	  Diffusion masks, CIF code, Transistors, Logical Gates,
	  Electronic Components...
E:	Do they (i) form a partitioning,
	or (ii) refer to some hierarchical description?
U:	They definitely do not form a partitioning.  
	(E.G. some CIF code may refer to a part of a transistor, etc.)
	Perhaps a hierarchy?
E:	In the Molecular Genetics example, which also had many components,
	these components formed a nice abstraction hierarchy. Do these here?
U:	Not quite.  Here a part/whole relation enters as well.
	That is, one physical object may be described in many ways, depending
	on the level of description.
	Certain diffusion masks may encode the pattern associated with a 
	particular Transistor.
	Similarly a collection of transistors may collectively form a Logical Gate,
	e.g. a NOR gate.  
E:	Ah, so this is an abstraction hierarchy, merged with a part/whole one.
	Let me create a new type of link, one which would join, say,
	Transistor#203 to Logical Gate#5.
	This will indicate that Transistor#203 is a part of a group of Transistors
	which collectively functions as (or "is an alternate description of")
	this Logical Gate#5.

{There is now more interaction: to describe how parts can be built up,
replicated, and placed, using the diffusion masks, on the silicon wafer itself.
Much of this refers to the parts of the design process itself, as this is
general VLSI knowledge.}

E:	I think I understand the basic VLSI ideas. Now to understand your task.
	First, what will be its output?
U:	It will be the CIF code for this chip.
E:	And what is the input to the task?
U:	It will be a list of components.
E:	What do you mean by component, in this case?
U:	One of the VLSI objects I decribed above.
E:	How should each of them be specified?
U:	That depends on the level -- each will be described in terms appropriate
	to this level.
E:	Please enumerate:
U:	The user may know a certain part of the chip in terms of actual diffusion
	layer, while others can only be described in terms of a certain complex,
	abstract CPU device, possibly based only on an I/O specification.
E:	So the input will be a list of object, where each object can be described
	in the terms of any of the classes associated with the Component hierarchy
	given above.  Correct?
U:	Yes.
@END[Verbatim]

{More dialog ensues, further defining the task. Eg what linguistic rules
would be employed for entering data, the name of this expert, some analysis
of the physics needed to understand and debug Integrated Curcuits in general, ...}

-----
@SubSection[After input, EURISKO thinks]

This concludes the input phase.  
Notice the domain expert was only asked question about the VLSI 
(and superordinate) domains, and NOT about
implementation level issues, such as how the data should be represented,
or what procedures should be used to perform the inferences needed.
As we will show below, EURISKO is able to make these decisions, 
(or at least, proposes suggestions).
[These judgments are based on knowledge EURISKO has stored on these topics,
which was either enterred by some user, or
determined from empirical data
(on things like success rate,) gleaned from its past experiences.]
[See section ? for more on this.]
The user also said very little about the rules and heuristics which
should be used.  
We will see that many of these, too, can be determined automatically by EURISKO.
[Section ?' motivates both why EURISKO should do this, and suggests how
it can be accomplished.]
@Foot[For comparison,
realize that the standard protocol for initiating a new KB has 
the domain expert (or the human system designer)
performing a host of (often fairly mechanical) chores.
He is usually expected to (1) write his own presonal representation language,
(2) implement his particular form of control mechanism, and then,
after inputting the actual domain specific data for his problem,
(3) enter the rules pertanent to this domain.
We feel a sophisticated program can eliminate, or at least assist,
the user in performing these three tasks.]

After that dialog, and some private deliberation,
EURISKO decides how the data should be represented,
proposing that frames, [consisting of gestalts
(called units) whose information is stored as the values of one or more properties,
(called slots),] be used.
This decision was based on the observations that
(1) simple binary relations seemed adequate for this case
(i.e. there seems no need for arbitrary n-ary relations,)
and, (2) as there was an open-ended set of properties,
a simpler record structure would not be sufficient.

EURISKO further suggests that each of the VLSI components
have multiple perspectives, ala KRL [Bobrow & Winograd].
Each of these will give it some features.  So, for example, each component 
@BEGIN[Verbatim]
	- viewed as a diffusion imprint, has a certain size, shape and location.
	- viewed as functional electronic component, has a PullUp and
		PullDown Resistivity.
	- when printed, has an associated set of stipple pattern.
@END[Verbatim]
(This idea was considered because of the "consider using many perspectives" rule
which was given above.  It had been derived from VLSI's connection
to Computer Science, via Electronics.)

Note this representation design came after the operations to be performed
on the data had been determined.
(While the actual code for the retrieval procedures has yet to be selected,
(see next paragraph,) its basic I/O definition has already been decided.
In this particular example, the major operation was the design process,
which had been prestored in one of EURISKO's task-solving KBs.
In general, EURISKO may have to actually build it from parts,
or from scratch. 
@Foot[4. Such building operations can actually generate the executable LISP code.
One procedure
(itself guided by processes which are themselves embedded in EURISKO,)
is to combine two almost-right modules.]
Analysis of Algorithms people have long realized the advantages in knowing the
operations FIRST, before deciding on the particular encoding to use. 
(Consider the work [Kant], [Barstow], as well as [AHU] and [Knuth].)

Based on these above decision, the appropriate inference/retrieval mechanism is
selected. 
In this case it is, once again "in stock".
This is because this "multiple perspective frame" encoding scheme was
one of the standard accessing modes.
(Otherwise RLL would have (tried to) construct it.)
For example, when requesting information about some unit,
the caller will have to supply not only the name of the unit,
but its current perspective as well.

The control mechanism is also easily determined
-- it is built by refining the control process associated with
the general "design" algorithm to this particular VLSI case,
and "multiple perspective frame" representation.

Next the Heuristic KB is set to work
given the task of proposing rules which may improve
the efficiency of the particular 
"design VLSI CIF code from a multi-layered description of the curcuit"
chore.)
It succeeds in generating the following rules:
(Each rule is followed by a brief explanation of its derivation.)

To explain some occurence, first use the explanation found in the 
(causal model for VLSI,) Electronics.
Only if that fails should you resort to "first principles"
(i.e. try to use the deeper model from physics.)
	[Built by specializing the Explanation Rule which says to try the
	 shallow model's explanation before going to the deeper model.
	 (as the first is, by definition and use, simpler).]
Use only regions bounded by Horizontal and Vertical lines.
	[Built from the General Task Rule: Try to keep things simple.
	 Here, it had first gone through the Geometry Rule which indicates
	 H/V regions are simpler (i.e. have fewer degrees of freedom)
	 than regions in general.]
Simplicity of construction is more important than speed of execution.
	[Built from "Sacrifices may be necessary when task is too complex"
	rule, based on the projected complexity of this task.]
Try to build modules which can then be replicated.
	[A subcase of the above rule.  It uses the fact about Hierarchies that
	 If one solution works for many (sub)problems, use it whenever possible.
	 i.e. dividing a task into a group of identical ones means less work.]
Use ALUs whenever possible. 
	[Further specialization of the above rule.]
Fix the locations of the biggest objects first.
	[Specialization of the General Problem Solving heuristic of
	 "Working on maximally constrained/constraining subpart first".]
Use symbolic locations/sizes/... until the end.
	[Built using an analogy to a rule in the Molecular Genetics KB 
	 "Given an otherwise arbitrary choice, postpone it as long as possible".]
	.
	.
	.

These above rules are all created by either specializing a general rule, or
by analogy to a rule in a KB which performed a similar type of task.
Rules may be generated the other way as well
(i.e. as a generalization from a particular case).
EURISKO will ask the user to suggest other
rules, ones which he considers apt either for this VLSI design domain,
or for some other, closely-related field.

-----

@BEGIN[Verbatim]
U:	It will pay to keep a symbolic description of the various design parameters
	around. This way, when there is an improvement to the technology,
	it will be sufficient to make a single simple change, in one place.
	For example, call the inter-line spacing "lambda".

E:	Good idea. Adding that rule to the rules for the VLSI Design domain.
@BEGIN[Verbatim]

-----

If EURISKO later finds a similar rule in some other domain, it may set itself
the task of determining for what domain, and for which "constant"s,
this Parameterizing makes sense.
(EG does anybody talk about Avagadro's Variable?)
The answer is, of course, that this approach is applicable
in areas where those technological advances which effect some value
happen frequently.
If EURISKO notices this, it will generalize (by inducting on such observations)
to create the rule that it is good to keep technology-dependent values
parameterized in high-technology domains.

[As a side effect, EURISKO might also view this user with a little more admiration
-- i.e. it will follow more of his suggestions,
or at least thinking harder before rejecting any of his ideas.
This is just what EURISKO would do to any other process (e.g. heuristic or task)
which had supplied a good idea. 
@Foot[5. Notice this is dues to another rule: 
Stick with known winners, whenever possible.]

One final note on this particular rule, and the process which might generate it:
EURISKO might have encoundered the motivation for generating such a
"keep constants stored symbolically" rule of its
own volition, after it had been burned too many times having to recompute
a slew of values when some "constant" changed.]

@SubSection[Exploration stage]
End of part one. 
This VLSI Design KB, 
as a "distributed program" 
(distributed among logically (functionally) distinct units,
not physically seperate processes)
is now ready to be "run", and empirically tested, on its
designing chips task.
Minor errors, as found, can be readily corrected.
(For example, the user may find that some domain fact is inconsistent 
based on some (possibly user-defined) criteria for consistency; or inadequate.)
Details can now be added, and small refinements made.  
Such small revisions are easy, and could be performed within any expert-building
system.
Below we show that even large modifications can be made, easily.

Unless specifically overridden, 
the basic mechanism used for designing VLSI chips will be the
one EURISKO supplies.
This process 
(1) can readily use the new heuristics which were generated to improve its output,
and 
(2) collects data on things like the performances of various processes,
heuristics, etc.).
EURISKO uses this data to judge how well these components worked
when considering whether to improve them, and to provide clues on how to
correct them.
This improvement part of EURISKO will remain pretty much in the background
when the user is working, except when:

-----

I. the user makes a specific request for EURISKO's intervention.
For example,
he may be concerned with the time this design process is taking,
and ask that improvement module to spend some time, now,
to optimize the algorithms used.
Or he may want EURISKO to examine and twiddle the particulars of 
his specific operations --
to figure some way to produce a particular layout in a slightly smaller area,
even if that requires that the regularity of the design
and/or speed of execution be sacrificed.

(Of course, changes such as like these could have been performed
by the system coder in any other programming environment.
The novelty here is that the `computer naive' user is able to issue the
reqest, and rely on EURISKO to find the relevant things to change,
and perform the modification.)

II. EURISKO, in some lax time, is trying to make
its general self a bit more efficient.
During this "introspection",
it may notice it has used a certain layout configuration quite 
a bit, and therefore decide to make this generic pattern into something like
an ABSTRIPS' MACROP.
This way
future tasks will consider pattern, explicitly, in appropriate situations.
(Consider why ALUs became so commonplace.)

-----

There seems two obvious dimensions which can be used to describe a change to
EURISKO.
One is scope.
The examples above were all fairly local changes --
one more unit (or, at most, type of unit) was added to the system.
The next sub-section deals with more major changes that
EURISKO may effect, based on more global information.
Both major and minor alterations were prompted by the same exploration process,
given in Section ?.

The other axis for describing these changes is initiative: whether the user
(or EURISKO) gives the system an explicit goal, or something to correct
or improve (this was Case I above); versus when EURISKO just looks around
for things it can do to help improve the productivity of one of its programs
which happens to be called EURISKO - shown in Case II above, and in the next
sub-section.
@SubSection[Reconfiguration stage]

After operating for a while, either the user or EURISKO itself may decide
to modify this KB in some non-trivial manner --
e.g. change some basic part of its processing,
or alter its basic encoding conventions.
(This may be due to some local observation, as mentioned in the last subsection,
or to more global considerations, based on several episodes of running
this design process.)

EURISKO might ask what would happen if certain constraints were lifted. 
For example, as a consequence of the fact that it produces CIF code,
the only components EURISKO can consider are rectangular in shape ,
built using only horizontal and vertical lines.
A brief investigation might show that if diagonal lines were permitted,
vastly superior curcuits could be designed --
e.g. both considerably smaller, and much less power-hungry.
EURISKO would then pursue the possibility of designing these more-arbitrary
components.
This would mean, for example,
that CIF code could not be the output.
Hence much more computation would be required to produce the chip,
both to produce these lower-level descriptions, and
to consider such non-rectangular parts.
If it still seemed wortwhile (e.g. if EURISKO calculated it could still
perform this task within the resourse constraints it was given,)
it would then ask for permission to 
generate the actual diffusion masks from now on.

Another types of change would effect the representation used for this task.
EURISKO may observe that it was often discussing n-tuples, where n>2.
It is both awkward and inefficient to represent this using
the current formalism, based on the inherently binary slots.
EURISKO therefore decides to recode all the VLSI KB using proposition,
which are based on arbitrary n-ary relations rather of slots.
(This decision, once made, is easily achieved.
The underlying representation language, RLL,
has sufficient "smarts" 
(1) to update all the accessing functions to conform to this new convention,
as well as (2) to perform the retroactive reconfiguration of the current data.
In fact, as RLL has performed this task was done before, it even
has the compiled code which does this.)

EURISKO often knows of several functionally-equivalent methods
for achieving some task.
For example, there are two basic approaches to solving planning types of problems.
One is the delay-decisions-as-long-as-possible technique,
which [Stefik] used in his Molecular Genetics experiment planning program.
This causes symbolic description to be used for underspecified objects,
which must then be propogated throughout the calculations.
The obvious alternative is to simply guess at the value
at the first opportunity.
Of course systems using this approach are forced to
to backtrack each time that guess is found to be wrong.

To compare these approaches, suppose a component had to placed somewhere in
a region.
The first approach would advocate placing this component at some
arbitrary position, say the left hand corner of region, location <23,47>.
The other method would be to locate this part at the symbolic location, <x,y>,
where x and y would each have to satisfy certain constraints.
Only when the full problem was solved, or when the permissible values for <x,y>
became a singleton, would that symbolic location be replaced with a constant value.

Based on the success of [Stefik], 
EURISKO would probably start using that first approach.
It would, however, collect empirical data by
monitoring the amount of work done during each task.
At some time EURISKO may decide to actually compare these two approaches,
with respect to this particular problem.
(This task could be generated by either EURISKO or the user.
For example, EURISKO may have been told
it is taking too long or using an inordinate amount of space for this
designing task.
Then again, EURISKO might simply have had some free time,
and decided it would be interesting to collect some addition data about these two
approaches.)
It would then try experimenting with the other approach,
using the data from these earlier cases.
If it finds this latter approach to be overall more efficient,
it will perform the mechanical adjustment necessary to effect this change.

This new evidence may cause EURISKO to reevaluate why it opted for that
first approach, anyway.
Given enough counterexamples, such as this case, it may decide
the second, "guess now, backtrack later" process should henceforth be its first
choice for new problems.
EURISKO may also check other KBs which use this postponing approach,
with an eye towards rewriting its code to reflect the other philosophy.

As a side effect of this side effect, EURISKO may then examine
those rules which had led to this first "postponing" decision
in the first place.
Each of these would be given a "demerit" based on this episode,
which would make it less persuasive in future cases.
(Of course, EURISKO might then generate a task
to find out why these rule had failed, further propogating the effects of
this empirical evidence.)
@SubSection[Closing remarks]
After a few iterations of this test and adjust cycle, we might be justified in
claiming that EURISKO has "learned" this new VLSI domain.
Some later task, say power plant construction,
can now use the facts EURISKO has accumulated about multi-layered objects.
Similarly this VLSI information can be used for a different task --
e.g. to verify a chip performs some function,
or to compare a set of similar chips, based on timing criteria, power usage, etc.
It is also a new source of metaphors, particularly applicable to other
subdomains under Electronics.

We would like to emphasize here that essentially all of EURISKO's aspects shown
in this scenario are flexible and adjustable.
Based on EURISKO's ability to interspect and redesign itself, much
more grandious changes to this system itself are possible.
It is possible major chunks of EURISKO's whole approach
to KB design might be modified.
For example,
after building a KB which dealt with interactive description refinement,
IDR-1,
EURISKO might compare this program with other programs with a similar task,
such as the process EURISKO used for inputting KBs, Initialize-KB.
If that IDR-1 KB used a user model to good advantage,
EURISKO might borrow that idea and apply it
to its own Initialize-KB component.

	<Transition>

Examples like the last point should convincingly demonstrate the utility
of being able to critically inspect and modify one's own code.
This concept is critical to EURISKO's operations, and is manifest
throughout the EURISKO system.
We will see in the upcoming section how even its underlying
representation language has this elegant property.
After this, in the discussion of heuristics, we will see that each heuristic
is explicitly represented, which means it may be readily alterred, and reasoned
about.

*** Where should I put details of EURISKO's control loop? Here? ****

@Section[Underpinnings]

@Subsection[Why a representation language?]

Before EURISKO can begin to probe about a domain like VLSI design,
it must first know at least the rudiments of this domain 
-- e.g. a modikin about diffusion layers,
and a lot about (existing knowledge of) layout design.
Knowledge about a deeper model, (here physics,) while not positively essential,
is still quite useful for understanding subtleties like timing situations which,
if omitted, would assuredly emerge to clog things up.

This information must, of course, be entered into the EURISKO system.
Given the vast amount of facts which must be entered
for each of these diverse fields, it is clearly advantageous to
provide a medium which the `experts' consider both natural and perspecious.
As the preceding dialog showed,
EURISKO allowed the expert to use terms he 
thought were appropriate
(as opposed to using those terms which happen to be built into
the computer system he happens to be using).

It was problems like these which gave rise to 
representation languages (rl) (see ?).
So it appears obvious that EURISKO (or at least its lingistic input/output part)
should be a solid, well-understood representation language.
Experiments like the one descriped in [Hayes-Roth, Waterman & Lenat] indicate
that no single pre-defined representation language will be adequate for any
arbitrary task.
Structures which seem sufficient for some types of problems (eg EMYCIN's Backward
chaining inference engine) do not lend themselves to other problem types
(here, back tracking to find the source of a spill).
For this reason, we decided to develope a slightly different type of representation
language; one which permits the user himself to significantly alter the 
structure of the language, to meet his expectations.

	<Why making this r l self-descriptive/self-modifiable solves this problem?>
Many researchers attempt to build the single ultimate representation language,
one which they boldly claim will address and solve all representation related
problems, current and future.
Time and again future users have found the purported generality was based only
on the rl's ability to handle all of the designers current's issues.

We have taken a quite different approach in designing the "final" rl --
simply make the language itself easily extendable.
RLL, for Representation Language Language, [Greiner & Lenat] 
has facilities for doing just that.
The trick is to make all of the components of the representation explicit.
So in RLL there is units dedicated to storing information about
each type of slot, others to encode the various accessing functions, etc.
The user can not only view these parts,
but can readily modify them as well.
These changes directly effect the language (that is his version of RLL)
he sees.
He can thereby fabricate his own novel rl,
by performing these straightforward modifications.
(An explanation of why and how this works is provided in [Greiner], and
[MRS].)

As EURISKO is constructed on top of this language, it has access to all of
RLL's "representational pieces".
Here EURISKO, rather than the user, can manipulate the language, to mold it
into the particular representation scheme needed for the current task.
This is why creating the new "abstraction merged with part-of" link was
so easy in the earlier example -- EURISKO needed only copy the unit which
represented the "is-an-abstraction" type of link, and modify this copy
to include the "part-whole" relation as well.
Upon the completion of this edit, 
EURISKO had generated a new type of slot.
@Foot[6. The "deepness" of this stored information is sufficient to allow the
user to readily design his own representational underpinning, by extracting
the particular parts from a group of rls which seem most appropriate.]

Even after his particular rl is constructed,
the user might decide the representation itself is too limiting,
or inefficient, or otherwise poorly chosen.  
Simple commands can effectively,
and efficiently, restructure the entire representational configuration,
or alter the particulars of the inference process.
for use in this new type of hierarchy.
One example was the ease with which
the VLSI KB was converted from slot- to proposition- based.
As facts about these two types of representations were explicitly stored,
EURISKO could reason about them 
(here, to determine how the data should be refitted
and to generate the new set of accessing functions.)

@Subsection[EURISKO uses same philosophy - leave everything explicit]
EURISKO also follows this "To everything, a unit" philosophy.
Everything is left as explicit as possible.
In particular, the inferencing and other processes are built out of
explicit, declarative modules, called rules, which can be individually
modified to cause the system to behave different.
For example, the interpreter responsible for "running" an agenda
is built up from a host of parts, each of which is a unit.
So to change this interpreter to, for example, run the task with the 
lowest interest, rather than the highest, would be simple. 
One would have to locate the chunk whose function was to return the
next task to run, and simply flip a bit there. 
The next time this agenda had to decide which task to run, it would
then select the least worthwhile one, as desired.
@Foot[7. As this chunk is built using a high level specification language,
this change would be simply changing a "<" to ">" -- the user
would never have to examine or twiddle any actual LISP code.
Such an encoding technique would allow a system devoid of Automatic
Programming knowledge to make such an alteration.
It becomes a trivial mechanical step, rather than an excruciating and
agonizing episode.]

Efficiency is often mentioned as a problem with this approach.
Using the ideas of Cognitive Economy [Lenat, Hayes-Roth & Waterman],
however, we see this is not justified.
Basically this approach is based on maintaining multiple versions
of the information, sufficiently linked together that any alteration to
any of these versions is reflected in the rest.
This is similar to the way INTERLISP handled compiled and interpreted code.
In general, the speedier compiled version is used,
except when you want to examine the code.
At this point an easier to understand (if slower to run)
interpreted form is loaded in and presented.
Any alteration causes the more compiled code to invalidated.

RLL is similar, in that many versions of a "program" 
(ranging from the compiled code down to those bite-sized rules)
are stored.
It does, however, go one step farther.
unlike IL, it will actually "recompile" this slower version during its
first use, and soon thereafter the slower, equivalent source will be 
swapped back out.  
In this manner the most efficient possible code is always available when
the task is execution, while an easier to understand version is left around,
which can be used for the goal is to understand the program, or modify it.

As undesired versions can be "swapped out" when not needed,
the extra cost for these extra versions is minimal.
As the most efficient code is used for execution,
there is no time penalty either.
(Actually there is a one-time overhead cost, of "recompiling".)

	<Lead in to Heuristics>
On type of easy to understand program-unit are heuristics.
As with tasks, agenda, and processes, there is a unit devoted to storing
the information associated with each heuristic.
The next section discusses what these heuristics are, how they are handled,
and why they are needed.
Below we discuss the perhaps-less-obvious reasons why automating the
incorporation of new heuristics is an important and useful process.

	<Why it pays to automate discovery of Heuristics>
Merely memorizing the "hard and fast facts" of a given domain
is sufficient to acquire an elementary "understanding" of that field.
Real expertise, however, requires more --
in addition to those solid facts,
the expert must also have "incorporated" the wealth
of the less solidly grounded "rules of thumb" or "intuitions",
associated with that domain.

Whereas domain facts are readily found in standard textbooks,
"heuristics" are notoriously difficult to articulate.
This explains why in many complex domains, from
artistry to medicine,
a long apprentiship is required to learn the nuances of the field.

Current AI efforts has show that
extracting heuristics from domain experts,
and incorporating them into a growing computer system,
is an equally difficult and time-consuming process.
Several solutions to this "transfer of expertise" bottleneck have been proposed.
Anything which aides the expert in articulating the rules is, of course,
helpful.
It is advantageous, for example,
to allow the expert to use a language which finds natural and
perspecious -- i.e. in which he can readily express
his terms and concepts.

Our solution is, instead, to further remove the human expert
from this overall learning process.
Given a relatively small nucleus of
powerful and general heuristics,
together with enough general, real world knowledge,
we believe many (perhaps most) domain heuristics can be mechanically derived.
We feel this task --
of automating the process of "incorporating" new heuristics --
is one of the most intriguing challenges addressed by the EURISKO project.
	<What are heuristics?>
Several important questions are now raised.
Just what is a heuristic?
How does one produce a new heuristic?
What mechanisms should be used to acquire the rules pertanent to some new domain?

Our difficulty in trying to answer the questions indicates how ill-defined
heuristics are (at least in the field of AI).
(The fact that these questions have only recently even be asked further
reinforces this point.)
It seems necessary to (at least begin to) formulate
a theory of heuristics before beginning to implement a system as dependant on
them as EURISKO is.
Ideally, this theory would not only describe what heuristics are,
but also how they interrelate with one another 
(e.g. noticing the natural ways a group of rules can be organized into a
specialization-of-applicatability hierarchy)
and how any given rule, as an individual component,
pertains to tasks and goals
(showing, for example,
that heuristic#43 can be "applied" to (that is, is relevant to)
task#81).
A discussion of these issues, while relevant, is beyond the scope of this paper.
[Lenat 80a] is a first stab at this type of formalization.

Our approach is based on the observation that "Heuristics" is itself a
{\sl bona fide} field
-- not unlike VLSI design, mathematics, or molecular genetics.
The only differences are in kind, not in nature.
Here the fundamental core units are these rules, rather than diffusion layers
or {\sl E.Coli} coding regions.
The reasoning processes required to
construct new proteins, or verify the accuracy of
some chip layouts, should be quite similar to those
a Heuristic knowledge base would employ to suggest
new rules, or to determine a given rule's domain of relevancy.

	<But heuristics are slightly different>
Heuristics do differ from nucleotide chains and diffusion masks in several
ways.
Unlike DNA strands, which the computer can only reference, heuristics
can actually be used by a running program,
(We will see later that we view them pretty much like LISP functions,
which can be applied to some arguments.)
This is NOT to imply that we cannot also reason about heuristics --
this is no more of a contradiction than realizing that
a Program Verificationist can examine, and draw inferences from,
a piece of, say, LISP code, which he can as easily execute.
(In section ? we will show how our representation allows us both views of
heuristics, without sacraficing efficiency.)
So this duality does NOT hamper our efforts to examine these computer generated
objects.
Indeed, it is the fact that they can then be `applied' in various domains
by EURISKO's own programs, that makes these entities worthy of study
by both EURISKO and us.

A more serious difference between these two categories of objects --
functions and heuristics on one hand, and DNA and game-playing on the other --
is the "indirectness" of the first group.
Whereas one
can simply enter data about chemistry, one can only refer to a heuristic
as a "heuristic about mathematics", or a 
"heuristic about explorations-in-general"
(or even, a "(meta-level) heuristic about heuristics").
For this reason, EURISKO must first acquire a host of "real world" domains.
These will provide EURISKO with the first bootstrap set of heuristics
it needs to develop a preliminary grasp of heuristics {\sl qua} field.
This, in turn, will be essential to determine
the plethora of characteristics associated with rules,
which is required to be able to build new ones.

	<How does EURISKO add new heuristics>
Given this "Heuristics is a field" idea, one can meaningfully ask
how to add in new elements: what mechanisms can be used to generate
new members, and in what ways these elements can be structured.
One approach to filling in this new field is by performing
a guided exploration: 
Given a small initial set of bootstrap rules,
one can use processes like specialization or analogy to 
derive new heuristics.
<<Example>>
One can similarly employ a small set of fundamentals about heuristics
to fill in attributes of these newly created rules.
<<Example>>
(Of course, these genesis processes are themselves heuristics;
and might thereby be affected by such processes - hopefully for the better.)

There is no reason to suspect the same exploration process 
which seems to work on other fields should not work as well here.
By insuring that EURISKO monitor its performance (or at least maintain
records on the activities which went on, and their respective results,)
EURISKO can judge the effectiveness of a certain program - here itself.
By this process, it may, from time to time, place a new task on the
current agenda - to see about improving some subprocess - which may,
in turn, involve honing the heuristics present, or attempting to generate
new ones.
(Of course, the user, or KB process in general, may equally well decide on
such a task.)
Independent of how proposed, EURISKO will access its general knowledge about
Heuristics (yes, which does include Meta Heuristics) to try to generate
or improve the set of rules now in use.

	<Known methods of generating heuristics>
Starting with a general rule, one can "bind" some of the variables form
a more specific one. 
This can make the code for executing the rule more efficient, as certain
tests become superfluous 
(i.e. can be evaluated during this "compilation" time,) and other parts
of the rule can perform fewer evaluations.

Side cases of this where some underspecified part of a rule (e.g. a random
guess) is replaced by a more restricted code (e.g. chose the left most
element,) or even a constant (e.g. return Task#32 here).
Many other specializations of this specializing rule are possible as well.
(This produces new rules whose domain of applicability is more restricted,
but which produce essentially the same result as the parent rule.)

The reverse process is called generalization. This goes from empirical data
to a single, "universal" rule.  
Determining the THEN-parts are straightforward -- these are what essentially
the observed facts.
The trick is finding the conditions under which this rule holds.
As these are only heuristics, as opposed to procedures guaranteed to work,
it is NOT crucial if the generated IF-part is faulty.  
By administering tests DURING the rule's execution,
these errors may be determined, and perhaps corrected.
(I.e. these become new empirical data, based on which the rule can be adjusted.)

Of the three methods analogy appears to be the toughest.
Given a rule, R1, in one domain, D1, analogizing programs
will try to find the essential commonalities which link D1
to the other domain, D2.
These links are then exploited in rewriting R1 to a form applicable to D2.
(Another method is (1) to find the generality, G, of which both D1 and D2
are specialization. Then (2) map corresponding parts of R1 to parts in G,
and finally (3) to derive  R2 by replacing those parts with their specializations
in D2.)
We do not yet have much to say about this.
Conclusion
 - note types of knowledge - meta and otherwise.  Perhaps
some subpart would be responsible for "knowledge about teaching", and
another capable of "knowledge about gathering knowledge", ...  Each of
these homonculi could be triggered to work, as appropriate.

EURISKO's two basic roles in life, from our perspective, are
(1) to find out interesting things, and as an interesting subproblem,
(and a means for EURISKO to improve its own performance)
(2) map out the space of heuristics, and generate new rules in the process.
As mentioned above, this presupposes a wide scope of knowledge bases,
covering a wealth of diverse domains.
To gather this information, we Heuristic Researchers hope to enter
a symbiotic relation with other EURISKO users, who will see this system
as a combination of representation language with (hopefully)
sophisticated expert system building program.
They will get a fully supported program; and in exchange, we take the
liberty of "looking over their shoulders", to examine the rules they
derive.  
Furthermore, as shown above,
these users will be able to use
EURISKO in creating and refining their rules.
(EURISKO will not be passive either -- throughout this process it will
be refining and updating its own knowledge of rules, as well as what
it knows about representations, control mechanisms, etc., based on
information presented by that user.)

Below we list what we consider to be the
basic (proported) contributions this EURISKO project makes to the field of AI:
	i.	Idea of guided search/exploration in arbitrary domains
	ii.	RLL concept
	iii.	View of heuristics 
	iv.	Leaving everything explicit, especially the interpreter
	    (of components in general -- using the Cog Econ philosophy)
Acknowledge

The author would like to thank the many people who have helped guide
the otherwise random process of generating (the ideas for) this EURISKO
system.  This whole EURISKO concept, and much of its research directions,
are due to Professor Douglas Lenat, who is instrumental in its (ongoing) design.
Prof Micheal Genesereth also played a large role, especially in the
representation related issues confronting this enterprise.
This entire system is built upon a demand paging algorithm, to sidestep
InterLisp's 256K core limitations.  This program was written by David Smith.
Our work in supported by ARPA Contract #?  and NSF Grant #?.
	References
RLL
MRS
AM
Cog Econ
VLSI
AA (AHU)
Stefik (delay decision)
KRL
Minsky
ABSTRIPS
Meta Comments

	Additional stuff in eventual paper
(More added as future research explores these areas)
Ways of encoding procedures (ie what needs to be said about them)
Future KBs
Results - new heuristics added (which surprising/expected)
	[which existing rules were fruitful & which irrelevant]
Operations in general - bottlenecks...

Note to distinguish fact from heuristic
KB refers to data, and to inferences done using them...